1. Field of the Invention
This invention is related to the field of processors and systems employing processors, and more particularly to tracking non-posted writes in such systems.
2. Description of the Related Art
A processor typically uses read and write transactions (generated in response to load and store instructions, respectively, in the software executing on the processors) to communicate with various devices included in the system with the processor. Among other things, the reads and writes may be used to configure the devices (e.g. during initial bring up of the system), to change the configuration during operation, to control the devices, to generally communicate with the devices, etc.
In some cases, the software may need to be able to determine whether or not certain writes have reached the target device. For example, “device driver” software (which is typically coded specifically for the target device, to directly interface with the device on behalf other programs such as of the operating system and/or application programs that may be running on the processor as well) may frequently need to determine that writes initiated by the device driver software have reached the target device. The device driver software may need to be able to determine that writes which change the configuration of the target device (and thus may cause the target device to behave differently for subsequent reads and writes to the device) have reached the target device. As another example, the device driver software may program various registers in the device to perform a specific operation. The device driver software may need to determine that these writes have reached the target device before issuing a read or write which causes the specific operation to start. Other types of software may similarly have a need to determine that a given write or writes have reached a target device.
Many processor architectures (e.g. the MIPS architecture, as one example) treat a given write by the processor as completed once the processor successfully transmits that write on the interconnect to which it is coupled. This may often be before the write reaches the target device. Thus, the instruction set of the processor does not, itself, provide a means for determining when the write has reached the target device.
Software has attempted to “determine” that a write has reached the target device by simply waiting a specified amount of time deemed to be longer than the latency of the write reaching the target. However, the target device may be coupled to the processor through interconnect that may include one or more bridges and other devices which may be transmitting reads and writes as well. Thus, the latency of the writes to reach the target device may not be predictable, and may in some cases exceed the specified amount of time. Thus, the software may issue subsequent reads or writes before the given write reaches the target device.
Another attempt to “determine” that a write has reached the target device is to issue a read to the same address as the write in an attempt to “flush” the write. When the read data returns, the software assumes that the write has reached the destination. However, not all systems guarantee that reads and writes will be processed (and reach the target device) in the order issued. Thus, this mechanism may not ensure that the write has reached the target device.